Built-in types are not generics

- Implement some basic batching support for sync and async, running each
  request through request processing and response processing.
- Achieve this through context manager that prevents request sending while
  batching is in progress and re-allows when batching is done.
- Refactor batch middleware logic into Web3Middleware class
- Fix up the sync batch method to work by using the ``w3._is_batching``
  flag correctly.
- Refactor the batching logic in the manager to be a bit more readable
  and more performant - even if ever so slightly.
- Interestingly, using ``asyncio.gather()`` with x requests is still
  faster than batching the same amount of requests into a single
  batch request. More research into performance improvements is
  needed.
- Iterate on performance improvement ideas for batching
- Add basic tests for batch requests; minor typing & refactor

- When adding async requests to a batch for a batch request, handle the
  awaiting of extracting the request information in the manager instead
  of adding that overhead to the batch API.
- Implement ``add_mapping()`` for batch requests

- Legacy websocket
- IPC
- Persistent connection providers (async_ipc, websocket)

- Move request batching to a higher level public API on the ``web3`` module;
  make the implementation methods on the manager private.
- Create a proper ``AsyncWeb3ModuleTest`` class that can test differences
  between synchronous and asynchronous methods on the module that now exist.
  This gets rid of the parameterized tests that previously tested the
  static methods on both the ``Web3`` and the ``AsyncWeb3`` classes.
- Tighten up typing related to batch requests; add unsupported methods for batching with tests

- Generalizaing name change: ``BatchRequestContextManager`` -> ``RequestBatcher``
  since it is no longer just a context manager.
- Add API to batcher for clearing (``clear``) and cancelling (``cancel``) the batch.
- Add more tests around these changes.

- Only guarantee response `id` order for batch requests if every
  response has an `id` field. Otherwise, rely on the provider
  to return the responses in order and hope for the best. An `id`
  should really ever only be missing in very rare cases where the
  request object itself was not able to be parsed correctly. So,
  hopefully this proves to be robust enough for most use cases.

- unpack response formatters for better readability